SSDs are mass storage devices that are used in communication with a host device, such as a personal computer or a mass storage appliance to provide data storage for the host device. There are a number of different interface specifications for the host device to interact with the SSD. The type of interface specification used will usually depend on the specific interface used to connect the host device and the SSD. For example, where the interface is an interface that complies with the Peripheral Component Interconnect Express (PCIe) industry standard, then one such interface specification may be Non-Volatile Memory Express (NVMe). NVMe provides a streamlined protocol and standardized command sets definitions for the host device to interface with the SSD.
In operation, the SSD's memory controller internally generates system data used to manage the operation of volatile and persistent memory devices used by the SSD for storage. The SSD's system data may be, for example, metadata for host data written to the memory devices, logical-to-physical (L2P) look-up-tables (LUTs), the read/write count of logical block addresses (LBAs), timestamps of LBA updates, etc. Such system data needs to be maintained within the persistent memory devices (e.g. non-volatile flash memory devices) of the SSD so that data stored within the SSD can be recovered after a shutdown or system failure. The memory controller, therefore, needs to also be able to manage internal system data. However, in typical SSDs, the memory controller manages internal system data in a different manner than data received from the host device. The memory controller is usually configured to use a proprietary protocol to manage the internal system data, while using a standard interface specification, such as NVMe, to manage host data. This arrangement of two parallel set of protocols, one for host data and the other for local system data, increases the complexity of the SSD's memory controller firmware.
Moreover, due to the use of separate protocols, locally generated system data and host data are stored in separate areas within the SSD's persistent memory. Given this, the area reserved for local system data cannot be used to store host data, and vice versa. This arrangement may reduce the storage capacity of the SSD as the host data cannot be written in the area reserved for local system data even when such area is effectively empty. Further, given that the local system data and host data are separately stored in a SSD memory device, namespaces for host data and local system data must also be separately maintained and managed. Correspondingly, other memory management operations, such as garbage collection, wear leveling, bad block management, and power loss protection, must also be separately conducted for local system data and host data, further increasing the complexity of the SSD's firmware.
Accordingly, there is an unmet demand for an SSD having uniform management of both host data and local system data and reduced firmware complexity.